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Abstract 


This document defines an alternative connection model for Message 
Session Relay Protocol (MSRP) User Agents (UAS); this model uses the 
connection-oriented media (COMEDIA) mechanism in order to create the 
MSRP transport connection. The model allows MSRP UAs behind Network 
Address Translators (NATs) to negotiate which endpoint initiates the 
establishment of the Transmission Control Protocol (TCP) connection, 
in order for MSRP messages to traverse the NAT. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6135. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The Message Session Relay Protocol (MSRP) core specification 
[RFC4975] states that the MSRP User Agent (UA) that sends the Session 
Description Protocol (SDP) offer is "active", and it is responsible 
for creating the MSRP transport connection towards the remote UA if a 
new connection is required. The core specification also allows, but 
does not define, alternate mechanisms for MSRP UAs to create MSRP 
transport connections. 


[RFC4145] defines a connection-oriented media (COMEDIA) mechanism, 
which endpoints can use to negotiate the endpoint that initiates the 
creation of media transport connection. 


COMEDIA is especially useful when one of the endpoints is located 
behind a Network Address Translator (NAT). The endpoint can use the 
mechanism to indicate that it will create the media transport 
connection, in order for the media to traverse the NAT without the 
usage of relays and without being required to support more complex 
mechanisms (e.g., "TCP Candidates with Interactive Connectivity 
Establishment (ICE)" [ICE-TCP]). In addition, COMEDIA allows the 
usage of identical procedures in establishing Transmission Control 
Protocol (TCP) [RFC0793] connections for different types of media. 


An example is the Open Mobile Alliance (OMA)-defined "Instant Message 
using SIMPLE" [OMA-SIMPLE], where one MSRP UA of every MSRP transport 
connection represents a media server, which is always located in the 
carrier network. The media server has a globally reachable IP 
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address and handles application-specific policy control as well as 
NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA for NAT 
traversal, and all OMA IM MSRP clients support COMEDIA. 


This document defines how an MSRP UA uses COMEDIA in order to 
negotiate which UA will create the MSRP transport TCP connection 
towards the other UA. The document also defines how an MSRP UA that 
uses COMEDIA can establish an MSRP transport connection with a remote 
UA that does not support COMEDIA. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


3. Applicability Statement 


Support of this specification is OPTIONAL for MSRP UAs in general. 
UAs that are likely to be deployed in networks with NATs SHOULD 
support this specification. It will improve the odds of being able 
to make TCP connections successfully traverse NATs, since UAs behind 
NATs can be requested to initiate the establishment of the TCP 
connections. 


4. COMEDIA for MSRP 
4.1. General 


This section defines how an MSRP UA that supports this specification 
uses the COMEDIA SDP attributes defined in [RFC4145]. 


4.2. a=setup 

4.2.1. General 
An MSRP UA uses the SDP a=setup attribute [RFC4145] in order to 
negotiate which endpoint will create the MSRP transport connection 
towards the other UA. 
An MSRP UA MUST always include an explicit a=setup attribute in its 
SDP offers and answers, since it might be useful for the other 


endpoint, or for entities in the network, to know whether the UA 
supports COMEDIA or not. 
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An MSRP UA MUST support the a=setup "active", "actpass", and 
"passive" attribute values. An MSRP UA MUST NOT send the "holdconn" 
attribute value. If an MSRP UA receives the "holdconn" attribute 
value, it MUST ignore it and process the message as if it did not 
contain an a=setup attribute. 


4.2.2. Attribute Usage 


When the a=setup attribute value is "actpass" or "passive", the IP 
address and port values in the MSRP URI of the SDP a=path attribute 
MUST contain the actual address and port values on which the UA can 
receive a TCP connection for the MSRP transport connection. 


In accordance with [RFC4145], if the a=setup attribute value is 
"active", the port number value should be 9. 


If an MSRP UA can provide a globally reachable IP address that the 
other endpoint can use as a destination for a TCP connection, the UA 
MUST use the a=setup "actpass" attribute value in SDP offers. This 
is in order to allow the remote UA to send an SDP answer with an 
a=setup "active" attribute value if the UA is located behind a NAT, 
and in order to be compatible with UAs that do not support COMEDIA 
and thus always will act as passive endpoints. If an MSRP UA cannot 
provide the actual transport address, the UA MUST use the a=setup 
"active" attribute value. 


The UA MUST NOT use the a=setup "passive" attribute value in an SDP 
offer. 


The MSRP UA can determine that it provides a globally reachable IP 
address in the following scenarios: 


o the UA can determine that it is not located behind a NAT; 


o the UA relays its MSRP transport connections via a relay (e.g., an 
MSRP relay or Traversal Using Relay NAT (TURN) server); or 


o the UA has used Session Traversal Utilities for NAT (STUN) 
[RFC5389] signaling to retrieve the NAT address and port through 
the local port to be used for the eventual transport connection, 
while also having determined that the NAT has endpoint-—independent 
mapping and filtering behavior [RFC5382], e.g., using the 
mechanism defined in [RFC5780]. 


Some UAs can determine whether the SIP [RFC3261] signaling has 
traversed a NAT by inspecting the SIP Via header field in the 200 
(OK) response to the initial SIP REGISTER request, and comparing the 
IP addresses in the Via sent-by and the received header field 
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parameters. If the IP addresses are not the same, then the UA can 
determine that there is a NAT in the path. Even though the media 
transport might not traverse the NAT, it is safe to assume that it 
will. This comparing mechanism does not work in all scenarios, 
though. For example, if SIP a request crosses a SIP proxy before 
crossing a NAT, the UA will not be able to detect the NAT by 
comparing the IP addresses. 


If an SDP offer includes an a=setup "actpass" attribute value, the 
SDP answerer MAY include an a=setup "active" attribute value in the 
SDP answer, but SHOULD include an a=setup "passive" attribute value 
if it knows that it is not located behind a NAT. 


Once the active UA has established the MSRP transport connection, the 
UA must immediately send an MSRP SEND request, as defined in 
[RFC4975]. 


NOTE: According to [RFC4975], the initiating UA is always active, 
but when COMEDIA is used, the a=setup attribute is used to 
negotiate which UA becomes active. 


4.3. TLS 


If an MSRP UA conformant to this document uses Transport Layer 
Security (TLS), it MUST use the TLS mechanisms defined in [RFC4975] 
and [RFC4976]. 


According to [RFC4975], the connection can be established with or 
without TLS mutual authentication. In case mutual authentication is 
not used, the listening device waits until it receives a request on 
the connection, at which time it infers the identity of the 
connecting device from the associated session description. From the 
TLS authentication point of view, it is thus irrelevant whether an 
endpoint takes the active or passive role. 


If an MSRP UA uses a self-signed TLS certificate to authenticate 
itself to MSRP peers, it also includes its certificate fingerprint in 
the SDP. 


Note that fingerprints can only be exchanged in peer-to-peer 
communication, as MSRP relays [RFC4976] will not receive the SDP 
payloads containing the fingerprint attributes. 

4.4. a=connection 
MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] 


defines connection reuse procedures for MSRP, and this document does 
not modify those procedures. 


Holmberg & Blau Standards Track [Page 5] 


RFC 6135 MSRP February 2011 


If an MSRP UA receives an a=connection attribute, the UA MUST 
ignore it. 


4.5. MSRP Relay Connection 


If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST 
always initiate a transport connection towards the relay, no matter 
what value the client has provided in the a=setup attribute. 


NOTE: Even if an MSRP UA initiates the TCP connection towards its 
relay, the UA will only send a SEND request if the UA is active, 
based on the COMEDIA negotiation. 


5. Interoperability with the Connection Model Defined in RFC 4975 


An MSRP UA conformant to this document can interoperate with a UA 
that follows the connection model defined in [RFC4975]. However, if 
an MSRP UA conformant to this document is located behind a NAT, does 
not proxy its MSRP communication via an MSRP relay, and receives an 
SDP offer from a remote UA that follows the connection model defined 
in [RFC4975], then NAT traversal can only be achieved if the MSRP UA 
supports ICE [ICE-TCP] or if the network supports Session Border 
Controller (SBC)-assisted NAT traversal for TCP. 


6. Security Considerations 


According to the connection model defined in [RFC4975], the MSRP UA 
that sends the SDP offer becomes the active party, and it is 
responsible for creating the MSRP transport connection towards the 
remote UA if a new connection is required. 


When COMEDIA is used, either the sender or the receiver of the SDP 
offer can become the active party. [RFC4975] requires that the 
active party immediately issue an MSRP SEND request once the 
connection has been established. This allows the passive party to 
bind the inbound TCP connection to the message session identified by 
the session id part of its MSRP URI. The use of COMEDIA does not 
change this requirement, but the sender of the SDP offer is no longer 
assumed to always become the active party. 


The active party also takes the role of the TLS client, if TLS is 
used to protect the MSRP messages. However, there are no procedures 
in [RFC4975] that would break in case the receiver of the SDP offer 
takes the role of the TLS client, and the level of security provided 
by TLS is not affected. 
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